NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/837

Text File | 1996-08-06 | 4.1 KB | 93 lines

Path: engnews1.Eng.Sun.COM!usenet
From: James Kanze US/ESC 60/3/141 #40763 <[e-mail]>
Newsgroups: comp.std.c++
Subject: Re: initialization of nonlocal static objects
Date: 25 Mar 1996 16:16:43 GMT
Organization: ?
Approved: [e-mail] (comp.std.c++)
Message-ID: <[e-mail]>
References: <4j1tm6$[e-mail]>
NNTP-Posting-Host: taumet.eng.sun.com
In-Reply-To: [e-mail]'s message of 24 Mar 96 04:40:44 GMT
Content-Length: 3311
X-Lines: 71

In article <4j1tm6$[e-mail]> [e-mail]
(Jeffrey C. Gealow) writes:

|> I've encountered trouble with the initialization of nonlocal static
|> objects.  The following parts of the ARM are relevant:

|>   ARM 3.4
|>   The initialization of nonlocal static objects in a translation unit is
|>   done before the first use of any function or object defined in that
|>   translation unit.  Such initializations may be done before the first
|>   statement of main() or deferred to any point in time before the first
|>   use of a function or object defined in that translation unit.  The
|>   default initialization of all static objects to zero is performed
|>   before any dynamic (that is, run-time) initialization.  No further
|>   order is imposed on the initialization of objects from different
|>   translation units.

|>   ARM 3.4 annotation
|>   A useful technique for insuring that a global object is initialized
|>   only once and before its first use is to maintain a count of the
|>   number of translation units using it.

|>   ARM 7.1.6
|>   A const object may be initialized, but its value may not be changed
|>   thereafter.

|> Are the following observations correct?

|>   The technique described in the ARM 3.4 annotation cannot be applied to
|>   const objects since the values of the objects may not be changed.

No.  Const has nothing to do with the question, since objects only
become const after construction.

|>   The ARM 3.4 guarantee that the "initialization of nonlocal static
|>   objects in a translation unit is done before the first use of any
|>   function or object defined in that translation unit" is not accurate.
|>   Functions or objects defined in a translation unit may be used in the
|>   initialization of nonlocal static objects defined in other translation
|>   units.  Therefore, mutual dependencies may make it impossible to honor
|>   the guarantee.

Correct.

|>   The C++ standard could be revised to include a guarantee that whenever
|>   possible, the initialization of nonlocal static objects in a translation
|>   unit is done before any function or object in that translation unit is
|>   used to initialize objects in other translation units.  Otherwise,
|>   const objects should not be used.

Somehow, I don't think that these exact words can be used.

I believe that the intent of the current draft is that rule in ARM 3.4
hold only for uses invoked directly or indirectly from main, but not
for uses which result from the construction of other static objects.

|> The Sun SPARCompiler C++ 4.1 and G++ 2.7.2 don't even honor the ARM
|> guarantee when there are no mutual dependencies.

And nor do any other compilers I'm aware of.  In practice, it is best
to assume that there are no guarantees whatsoever between compilation
units.  (On the other hand, it is generally safe to assume that all
initialization will take place before main, at least if you are not
using DLL's.  This is not guaranteed by the draft, however.)

--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
                -- A la recherche d'une activitΘ dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:[e-mail]         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:[e-mail]                             ]